home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12133 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: news.bbn.com!cbarber
  2. From: cbarber@bbn.com (Christopher Barber)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 18 Mar 1996 15:46:44 GMT
  6. Organization: BBN
  7. Message-ID: <CBARBER.96Mar18104644@figaro.bbn.com>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu>
  9.     <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net>
  10.     <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net>
  11. NNTP-Posting-Host: figaro.bbn.com
  12. In-reply-to: rmorin@inforamp.net's message of Sat, 16 Mar 96 08:03:03 GMT
  13.  
  14.  
  15. >>>>> "Randy" == Randy Charles Morin <rmorin@inforamp.net> writes:
  16.  
  17.     Randy> You see, I've worked on dozens of projects and most of them had
  18.     Randy> coding standards.  And most of those coding standards were
  19.     Randy> reasonable.  This coding standard was a joke.  You see, the
  20.     Randy> company even agreed that our group would not have to follow the
  21.     Randy> guidelines, because they were devised by an inexperienced group
  22.     Randy> that were not aware of the world outside of character based
  23.     Randy> Unix.  But, a couple of you inexperienced programmers have to
  24.     Randy> pull a hollier than thou routine.
  25.                   ^^^^^^^
  26.  
  27. Maybe becase we are all *ivy* leaguers? ;`)
  28.  
  29.     Randy> I received many responses
  30.     Randy> from users who agreed that the standards were a joke.  Some of
  31.     Randy> these were even posted publicly.  
  32.  
  33. Some of those were sarcastic!
  34.  
  35.     Randy> ------- -source files should have the extension .cc (not .cpp or
  36.     Randy> .c).  I don't think I have to say anything here.
  37.  
  38.     Randy>     -header files should have the extension .hh (not .hpp or
  39.     Randy> .h).  I don't think I have to say anything here.
  40.     
  41. Sure you do.  Do you really consider this an argument?
  42.  
  43. I think that it is perfectly reasonable to specify standard suffixes for
  44. source files and the ones chosen are not unreasonable.  Why confuse poor
  45. entry level programmers with multiple suffixes for C++ code?  
  46.  
  47. Clearly .c would be a really stupid choice for C++ code because there would
  48. be no way for a makefile to know when to use the C compiler and when to use
  49. C++.  For you to even suggest it as an option, indicates to me that your
  50. judgement is impaired.
  51.  
  52. I think it is ok to use .h as an extension, but only if it can be used
  53. with C code.
  54.  
  55.     Randy>     -inline C++ functions should be in a file with the
  56.     Randy> extension .icc (not in the primary header).  I don't think I
  57.     Randy> have to say anything here either.  But, I will.  Although I've
  58.     Randy> seen many people do this, it is contrary to normal industry
  59.     Randy> practices.  By using non-standard practices you increase the
  60.     Randy> learning necessary for new employees.  Bad.
  61.  
  62. There is no such thing as "normal industry practices".  Although a bit
  63. extreme, this convention does have some advantages: 
  64.  
  65.     - it keeps code out of the header in the spirit of seperating
  66.       interface and implementation
  67.     - it makes it relatively easy to switch between inlined and
  68.       non-inlined code.
  69.  
  70.     Randy>     -do not use the /* */ comment, except when commenting out
  71.     Randy> entire sections of code.  /* */ are the ANSI standard comment.
  72.     Randy> // are not.  When you have a parameter not used warning, you
  73.     Randy> should eliminate it using.  void f(int /* idControl */); You
  74.     Randy> can't do this with //.  You could also delete the identifier,
  75.     Randy> but then you would lose context.
  76.  
  77. Very true.  This is a place where the /* */ comments would be useful.
  78. But generally, it is easier to do special comment processing in smart
  79. editors if you use the // style comments, so I think that the rule is
  80. ok as long as you recognize that there are some places where the old
  81. style comments will make more sense.
  82.  
  83.     Randy>     -a class which can be instantiated with a "new" must have a
  84.     Randy> copy constructor, a destructor and an assignment operator
  85.     Randy> definition.  Most compilers (if not all) supply default copy
  86.     Randy> construtors.  Unless you think your class may have copy behavior
  87.     Randy> problems, then writing copy constructors is redundant.  When you
  88.     Randy> have 100+ classes to write and where the average copy
  89.     Randy> constructor has 50 lines, you would need 100 hours to write the
  90.     Randy> additional robustness (or cumbersomeness).
  91.  
  92. Aren't you getting a bit extreme here?  I have written hundreds of
  93. copy constructors and only a handful came even close to 50 lines long.
  94. Yes, the compiler will generate a copy constructor for you, but it
  95. has the wrong behavior in many cases.
  96.  
  97.     Randy>     -never use #define instead or const.  This is a good
  98.     Randy> debate, but I still maintain that if your memory model and
  99.     Randy> compiler make #define data text and const code text, then you
  100.     Randy> cannot consider this a straight forward trade-off.
  101.  
  102. Didn't you say this was a Unix project?  There is no such thing
  103. as a "memory model" in Unix.
  104.  
  105. Anyway, enough of this.  Some of the rules are a bit extreme or silly.
  106. But many are quite reasonable and you don't seem to be able to distinguish
  107. between the two.
  108.  
  109. cheers,
  110.  
  111. - Chris
  112. -- 
  113. Christopher Barber ----- Software Engineer ---- BBN Systems and Technologies
  114.